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(54) Title: SYSTEM AND METHOD FOR COLLABORATIVE DATA SHARING 
(57) Abstract 

A system and method for creating and modifying shared data 
in a collaborative environment is disclosed. A system for creating 
and modifying shared data includes a release manager module, a 
staging system and an on-line system coupled together through a 
computer network. The system allows users to create and modify 
data in the staging system and specify when such changes should 
be made to the on-line system. The on-line system maintains the 
most current version of the shared data and allows users to view and 
retrieve information. The staging system maintains the shared data 
which has been created or modified and which will be used by the 
release manager module in performing the release process. The release 
manager module controls the updating of the on-line system from the 
staging system and can perform incremental updating to only portions 
of the on-line system or full updating where all modified portions of the 
system are made current. A method for creating and modifying shared 
data includes updating a record in the staging system, packaging the 
record into an update package, transferring the update package from 
the staging system to the on-line system; and updating the on-line 
system. The present invention also includes methods for maintaining 
data consistency during the step of updating a record in the staging 
system. 
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WO 99/33007 PCT/US98/27444 
System and Method For Collaborative Data Sharing 

Inventors: 
Vani Kola and Kerman D. Deboo 
BACKGROUND OF THE INVENTION 
5 1. Field of the Invention . 

The present invention relates generally to the collaborative development and use of 
data in computer systems. In particular, the present invention relates to a system and method 
for creating and modifying collaboratively shared data. Still more particularly, the present 
invention relates to creating and modifying collaboratively shared data in an automated 
1 0 system for conducting business transactions for the purchase and sale of non-production 
goods. 

2. Description of the Background Art . 

Over the last decade, computer systems have undergone a gradual evolution from the 
single mainframe to distributed networks of personal computers and workstations. Because 
15 computer networks are extremely efficient at maintaining and communicating information 
and performing activities between distributed sites, modern businesses should be the 
obvious beneficiaries of this revolution in technology. For example, databases used by 
different departments within a business could be created, maintained and modified 
automatically over a shared computer network. 

20 One example where collaborative data sharing is essential is the purchase of 

non-production goods and services, often called MRO purchasing. At present, most business 
to business commerce is not automated and generally paper based. For example, a 
corporation's purchase of an item for a particular task is usually a manual process and is 
often very labor intensive. In the typical purchasing process 1) data needs to be gathered 

25 about the item to be purchased, 2) potential vendors need to be identified, 3) prices need to 
be compared, 4) a paper based requisition needs to be filled out and submitted for approval, 
5) the purchase requisition needs to be routed to a purchasing department for further 
scrutiny and approval, 6) the purchase requisition needs to be transferred or converted into a 
purchase order, 7) the purchase order needs to be approved and then submitted to the vendor 
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for fulfillment, and 8) the order needs to be tracked until the goods are delivered. This 
process is subject to much error due to the numerous manual steps in the process, the data 
transcription requirements, and the many different individuals that need to participate in 
routing the documents through the process. 

5 Thus, collaborative data sharing for use in automation of procurement has long been 

an illusive goal for many businesses. Some electronic resource planning (ERP) and 
electronic data interchange (EDI) systems have addressed part of the problem, but those 
solutions generally address specialist purchasing activities for a small user population in a 
business. Automation of procurement for the enterprise by allowing users to purchase those 
10 items they need, when they need them, and to significantly reduce the cost of that 
purchasing process has not been successfully addressed in the prior art. Moreover, 
numerous shortcomings in the state of the art prevent businesses from fully exploiting 
conventional network technology for collaborative data sharing in such an application. 

One particular problem specific to the collaborative sharing of data is the creation, 
15 modification, organization and dissemination of information maintained in shared databases 
in a consistent and orderly manner. The prior art has attempted to reduce such problems 
through the use of database replication programs. Database replication is a method for 
modifying, adding to or deleting data in a database. With conventional database replication, 
a user may access and download data from a master database. Once the data is downloaded, 
20 the user may modify, delete or add to the downloaded data. The modified data is then 
compared against and merged with the master database. 

However, conventional database replication programs suffer from a number of 
shortcomings. First, many different changes to data in a database may be entered by more 
than one user often resulting in multiple, concurrent, and conflicting changes. Prior art 

25 database replication systems do not always ensure that shared data modified by different 
users remain current, correct and consistent. Moreover, current database replication 
programs do not provide for verification and approval of changes before distributing the 
changes to the target systems. Another problem is that conventional database replication 
methods are usually implemented immediately and do not provide for modifications at pre- 

30 scheduled times. Additionally, it is often desirable to modify data a single time and have the 
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changes implemented in various separate target systems rather than having to modify the 
data for each particular system. Finally, current replication methods only address data in the 
database and cannot deal with data objects outside the database structure, e.g. images left in 
a general file system directory. 

Therefore, there is a continuing need for a system and method for collaborative data 
sharing in a multi-tier computer network. More particularly, there is a need for an automated 
system that utilizes such system and methods for collaborative data sharing in a multi-tier 
computer network for automated procurement. 

SUMMARY OF THE INVENTION 

The present invention overcomes the deficiencies and limitations of the prior art 
with a system for collaborative data sharing in a multi-tier computer network. The present 
invention is a system for performing a release process for creating, maintaining and 
modifying shared data in a collaborative environment and more specifically, for modifying 
data in a staging system to affect changes in an on-line system. The system for performing 
a release process in accordance with the present invention preferably comprises a release 
manager module, a staging system and an on-line system. The on-line system allows users 
to view and retrieve information. The present invention operates such that there may be a 
plurality of such on-line systems. The staging system provides access to users desiring to 
create or modify data in an on-line system. These users can modify the data in the database 
and specify when such changes should be made to any one of a number of on-line systems 
that are in existence. The release manager module controls the updating of the on-line 
system from the staging system and can perform incremental updating to only portions of 
the on-line system or full updating where all modified portions of the on-line system are 
made current. 

The present invention also comprises a method for performing a release process for 
modifying data in a staging system to affect changes in an on-line system. The preferred 
method for performing a release process comprises the steps of: updating a record in the 
staging system; packaging the record into an update package; transferring the update 
package from the staging system to the on-line system; and updating the on-line system 
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using the update package. The present invention also includes methods for maintaining data 
consistency during the step of updating a record in the staging system and on-line system. 

One embodiment of the present invention is a procurement system for automating 
the procurement and purchase of items. A procurement system embodying the principles of 
5 the present invention preferably includes a release manager module for performing a release 
process and preferably operates on a computer network that includes one or more computers 
and a legacy or mainframe computer coupled by a computer network and/or the 
Internet/Intranet. The procurement system is preferably a web-centric application that 
comprises a thin client, a Web Server, and an application server and a database server. The 

10 procurement system also includes at least one staging system and at least one on-line 
system, each of which stores information used by the procurement system. The on-line 
system allows users to view and retrieve current information, and place and process orders. 
The staging system is accessible to authors of information, such as authors of data in a 
catalog, or authors of processes for handling orders. The release manager module controls 

15 the updating of the on-line system from the staging system. A procurement system which 
includes a release manager module allows users to modify data in the staging system and 
specify when such changes should be made to any one of a number of on-line systems that 
are in existence. 

BRIEF DESCRIPTION OF THE DRAWINGS 
20 Figure 1 is a graphical representation of transaction processes involved in a 

procurement system operating according to the present invention; 

Figure 2 is a block diagram of a computer system constructed according to the 
present invention including a procurement system; 

Figure 3 is a block diagram of a preferred embodiment of the memory including the 
25 components of the procurement system according to the present invention; 

Figure 4 is a block diagram of a preferred embodiment of the staging system and on- 
line system constructed according to the present invention. 

Figure 5 is detailed block diagram of the preferred embodiment of the purchase 
manager constructed according to the present invention; 
30 Figure 6 is a detailed block diagram of the preferred embodiment of the functional 

components of the procurement system constructed according to the present invention; 
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Figure 7 is a block diagram graphically showing the software architecture for the 
procurement system of the present invention; 

Figure 8 is a flowchart of a preferred method for performing a release process in 
accordance with the present invention; 

Figure 9 is a flowchart of a preferred method for updating the staging system in 
accordance with the present invention; 

Figure 10 is a flowchart of a preferred method for maintaining data consistency 
during the staging system of the release process in accordance with the present invention; 

Figure 1 1 is a flowchart of a preferred method for packaging data scheduled to be 
released in accordance with the present invention; 

Figure 12 is a flowchart of a preferred method for transferring packaged data to a 
target on-line system in accordance with the present invention; and 

Figure 13 is a flowchart of a preferred method for an on-line updating process in 
accordance with the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

While the present invention will now be described in terms of a procurement system, 
those skilled in the art will realize that the underlying structure and processes of the present 
invention apply to a variety of other business applications such as human resources, real 
estate, logistics, asset management, expense reporting, time card management, cross - 
enterprise management, and others, and the procurement system is provided only by way of 
example. 

Referring to Figure 1, a block diagram of a system 100 embodying the principles of 
the present invention is shown. A plurality of sites, 102, 104, 106, 108, 1 10, 1 12, and 1 14, 
are coupled to a network 1 16. In a preferred embodiment, system 100 is a procurement 
system and sites 102, 104, 106, 108, 1 10, 1 12, and 1 14 are business enterprises which act as 
customers, manufacturers, suppliers, and/or distributors. For example, site 102, acting as a 
customer site, accesses site 1 04, a multi-vendor catalog site, and searches or browses the 
catalog for a particular item. When site 102 has selected an item for purchase, site 102 
accesses site 106 and fills out a purchase requisition or purchase order. Site 106 submits the 
purchase requisition or purchase order to site 108, a vendor purchasing department, for 
approval. The purchase order is then submitted to site 1 12, a manufacturer or supplier, in 
-5- 
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order to fill the purchase order. Site 114 allows the customer to keep track of the order 
on-line. Sites 102, 104, 106, 108, 110, 112, and 1 1 4 communicate with each other over 
network 116. Each of sites 102, 104, 106, 108, 1 10, 1 12, and 1 14 is a computer or 
computer system as will be described below in more detail with reference to Figure 2. 
5 Network 1 1 6 may be any type of computer network system such as an intranet, the Internet, 
or an Extranet, and is preferably the Internet. 

System 100 is preferably a Web-centric, multi-tier application that allows 
connecting sites 102, 104, 106, 108, 1 10, 1 12, and 1 14 to work collaboratively to complete 
a business transaction. One advantage of the present system is its ability to eliminate errors 

10 caused by prior art manual procedures. Additionally, system 1 00 embodying the principles 
of the present invention reduces the time it takes individuals involved in the process to 
complete their portion of the transaction, thus reducing the overall cost of business 
operations. In a preferred embodiment, system 1 00 is a paperless procurement system 
which ensures that product information is always current and correct and that quick 

15 implementation of changes to catalog information, such as adding suppliers and products, is 
possible. A procurement system embodying the principles of the present invention provides 
multi-supplier item information in a single electronic catalog and allows self-service usage 
to the catalog user. System 100 also manages the creation of catalogs and ensures that all 
catalog changes are applied in an orderly manner and at the required time. It also allows 

20 catalog changes to be prepared and reviewed before they are published. New content can be 
staged and tested before it is published to the end-user. Once the changes are approved, 
those changes can be applied to the on-line production systems automatically. 

Referring now to Figure 2, a block diagram of one embodiment of a site constructed 
according to the present invention is shown. Typically, a site, such as site 104, comprises a 

25 computer system, a single server host or a cluster of hosts and a set of clients that 

communicate with the server host over a network. A preferred embodiment of a site 200 
comprises a processor 202, a memory 204, and a data storage device 206, an input device 
208, an output device 210, and a network/internet link 212. Processor 202 is connected by a 
bus 214 to memory 204, data storage device 206, input device 208, output device 210, and 

30 network/internet link 2 1 2 in a Von Neuman architecture. Processor 202, memory 204, input 
device 208, and output device 210 may be coupled in conventional manner such as a 
-6- 
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personal computer. Processor 202 is preferably a microprocessor such as an Intel Pentium 
processor; input device 208 is preferably a keyboard and/or mouse type controller; output 
device 210 is preferably a video monitor. 

Processor 202 is also coupled to data storage device 206, such as a hard disk drive, 
in conventional manner. Data storage device 206 contains an information source, i.e. the 
databases and directories that contain information managed by an information owner. In a 
preferred embodiment, data storage device 206 includes a non-production database or 
staging system 216 and at least one production distributed relational database or on-line 
system 218. Staging system 216 and on-line system 218 may be located on a single hard 
disk drive on a single server or separate hard disk drives on separate servers connected via a 
network connection. In a preferred embodiment, staging system 216 and on-line system 
2 1 8 are located on separate servers, such as a Pentium class server with at least 6 Gbytes of 
disk space, connected via a TCP/IP network connection. Staging system 216 and on-line 
system 21 8 are described below in more detail with reference to Figure 4. 

Bus 214 is also coupled to network/internet link 212 to facilitate communication 
between site 200 and other sites of the network. In a preferred embodiment of the present 
invention, network/internet link 212 preferably comprises a network adapter card including 
a transceiver that is coupled to a cable or line. For example, network/ internet link 212 may 
comprise an Ethernet card connected to a coaxial cable line, a twisted pair line or a fiber 
optic line. Those skilled in the art will realize that a variety of different networking 
configurations and operating systems may be used and that the present invention is 
independent of such use. 

Network/Internet link 212 is responsible for sending, receiving, and storing the 
signals sent over the network or within a protected domain of a given network. 
Network/Internet link 212 is coupled to bus 214 to provide these signals to processor 202 
and vice versa. 

Network/internet link 212 also facilitates communication between site 200 and other 
networks. Specifically, network/internet link 212 sends data and messages via bus 214 to 
other networks. For example, network/internet link 212 may include a modem, a bridge or a 
router coupled to the other networks in conventional manner. In a preferred embodiment of 
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the present invention, the network/internet link 212 is preferably a router or a high speed 
switch. 



Processor 202, under the guidance and control of instructions received from memory 
204 and from the user through input device 208, provides signals for sending and receiving 
5 data using network/internet link 212. The transfer of data between sites is broken down into 
packets or packages. A packet or package is a unit of data that is routed between an origin 
and a destination on the Internet or other network. Those skilled in the art will realize that 
site 200 may also be a mini-computer or a mainframe computer. 

Referring now to Figure 3, a preferred embodiment of the memory 204 for site 200 
10 is shown in more detail. Memory 204 is preferably a random access memory (RAM), but 
may also include read-only memory (ROM). Memory 204 includes a procurement system 
module 301 which preferably includes an open system interfaces module 302, a functional 
components module 304, a component application program interfaces (APIs) module 306, a 
purchase manager module 308, a procurement APIs module 310, a purchase requisition 
15 (PR) application module 312, and a PR API module 314. Memory 204 also includes an 
operating system 320, and an API module 322. 

Open system interfaces module 302 is coupled to storage device 206 from Figure 2 
and typically includes industry standard APIs to the information source, i.e. the databases 
and directories that contain the information managed by an information owner. In a 
20 preferred embodiment, the information source is accessed via the Internet using hypertext 
transfer protocol (HTTP) and is assumed to be remote from memory 204. 

Functional components module 304 comprises components that provide the core 
functions for the invention. For example, in a preferred embodiment of the invention, 
functional components module 304 preferably includes functional modules such as an 
25 access control and administration module, a workflow rules module, a database access 

module, an information manager module, an authoring module, a release manager module, 
and a web driver. The operation of functional components module 304 for the present 
invention is described below in more detail with reference to Figure 6. 
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Component APIs module 306 includes APIs that abstract the functionality of the 
components into objects that are re-used in the construction of purchase manager module 
308. Component APIs module 306 provides standardized methods for individual modules 
to exchange information, take actions, and apply changes to data. The methods of these 
APIs are specific to the module and allow other modules access to data or services provided 
by a module. 

Purchase manager module 308 is a specialized server that enables applications for 
the overall procurement space. Purchase manager module 308 includes functions that are 
specific to procurement, including APIs to backoffice processing systems such as Oracle 
Financials, SAP, and BAAN. The operation of Purchase manager 308 is described below in 
more detail with reference to Figure 5. 

Procurement APIs module 310 includes APIs to the real applications used to deliver 
services and functions to the end-user, such as the PR Application. 

PR application module 312 is the purchase requisition application that embodies all 
the business rules for processing a purchase requisition, presenting all the information about 
goods that may be purchased, and the access control configuration for the system. 

PR API module 314 includes APIs that allow custom extensions to the standard PR 
Application, such as method to interface to legacy systems, or to processes that access 
pricing information. While procurement system module 301, open system interfaces 
module 302, functional components module 304, component application program interfaces 
(APIs) module 306, purchase manager module 308, procurement APIs module 310, 
purchase requisition (PR) application module 312, and PR API module 314 are shown as 
blocks of memory 204, such modules could also be continuous portions of memory such as 
in a computer program. 

The present invention preferably uses a conventional operating system 320 such as 
Windows NT. Those skilled in the art will realize how the present invention may be readily 
adapted for use with other operating systems. 
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Memory 204 may also include a variety of different APIs 322 including but not 

limited to computer drawing programs, word processing programs, and spreadsheet 

programs. 

Referring now to Figure 4, a preferred embodiment of the data storage device 206, 
5 staging system 2 1 6, and on-line system 2 1 8 is shown in more detail. Staging system 2 1 6 is 
coupled to at least one on-line system 218. Preferably, staging system 216 is coupled to at 
least one on-line system 218 through a network 402, which is preferably an Extranet or 
intranet. Data storage device 206 may also include a backend system 404 which is 
preferably a legacy or other system that contains data that could be used by the procurement 
10 system module 301 , or that stores output from the procurement system module 301 . 

Staging system 216 maintains all data entered by various creators. All data is created 
and modified on staging system 216 and then released to on-line system 218 at a specified 
time using a release process. A release process in accordance with the present invention 
allows a user to modify data in a staging system 216 to affect changes in an on-line system 
15 2 1 8 for use in a collaborative data sharing environment. Thus, staging system 216 

maintains data which is to be used during the release process to update an on-line system 
218. The operation of such release process is described below in more detail with reference 
to Figures 8, 9, 10, 11, 12, and 13. 

On-line system 218 maintains the most current version of the shared data in a 
20 collaborative environment. In one embodiment, one staging system 216 is used to populate 
multiple on-line systems 218. Each such on-line system 218 may have different contents, 
depending on the construction of the release process. In another embodiment, one on-line 
system 218 may be updated from multiple staging systems 216. 

Referring now to Figure 5, a block diagram of a preferred embodiment of the 
25 purchase manager module 308 constructed according to the present invention is shown in 
more detail. Purchase manager module 308 includes a catalog browser module 502, a 
shopping basket manager module 504, a purchase requisition manager module 506, a 
purchasing administration module 514, a purchase order manager module 512, and a 
workflow rules module 5 1 0. 
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Catalog browser module 502 is any compliant web browser, such as Netscape 
Communicator, that is used to view, and search the catalog for desired items. The catalog 
browser module 502 also provides access to all the other functions provided by the 
application. 

Shopping basket manager module 504 creates a shopping basket to allow a user to 
keep selected items until they are ready to create the purchase requisition. Shopping basket 
manager module 504 allows multiple shopping baskets to exist simultaneously. Shopping 
baskets may also be saved to become shopping lists for re-use. 

Purchase requisition manager module 506 offers the ability to create, edit, delete and 
submit purchase requisitions to procurement system module 301. A purchase requisition as 
defined for the purposes of the present invention is a data structure with data that is used and 
processed by modules within procurement system module 301 . Purchase requisition 
manager module 506 is also coupled to workflow rules module 510 and is used to control 
the sequence of actions necessary to approve a new purchase requisition. For example, 
purchase requisition manager module 506 may withhold approval of a purchase requisition 
until all required approvals are obtained. Purchase requisition manager module 506 offers 
an easy to use intuitive web application interface to deploy business-to-business purchasing 
without requiring any special knowledge relevant to webpublishing, such as database (DB) 
definition, servers, hypertext markup language (HTML) or common gateway interface 
(CGI). It offers administrative capabilities in managing the information infrastructure with 
respect to firewalls, security, release control and administration. 

Purchasing administration module 514 allows users to define application parameters, 
set default values, create company-wide shopping lists and enter workflow rules module 
510. 

Purchase order manager module 512 accepts approved purchase requisitions and 
transforms them into the required purchase orders to the required destination as defined in 
the application parameters. 

Workflow rules module 510 is the encoded form of company policy that specifies 
the sequence of actions required to move a new purchase requisition to a fully approved 
state (or purchase order) if required. Workflow rules module 510 also contains the encoded 
form of company policy that specifies the sequence of actions required to update staging 
system 216 and on-line system 218. Company policies are preferably entered by an 
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authorized administrator by way of workflow rules module 510 which preferably takes the 
form of a program executing on a stored program computer. The operation of workflow 
rules module 510 is described below in more detail with reference to Figure 6. 

Referring to Figure 6, a detailed block diagram of a preferred embodiment of the 
functional components module 304 of Figure 3 constructed according to the present 
invention is shown. Functional components module 304 preferably includes an access 
control and administration module 602, a database access module 604, an information 
manager module 606, an authoring module 608, a workflow module 610, a release manager 
module 612, and a web driver 614. The routines of the present invention for performing a 
release process primarily include release manager module 612, database access module 604, 
and information manager module 606. 

Access control and administration module 602 provides the means to define what 
actions (e.g. view, create, edit, delete) a user of the invention may execute and on which 
data objects those actions may be performed. Access control and administration module 
602 accepts data from and transmits data to release manager module 612. Access control 
and administration module 602 provides enforcement of access control policies such as data 
in staging system 216 or on-line system 218 which a user is prohibited from editing or 
deleting, or users which are prohibited from viewing certain data in staging system 216 or 
on-line system 218. Access control module 602 thus ensures that only permitted actions for 
a given user are executed. Access control and administration module 602 may also be used 
to schedule releases for each on-line system 218 on a regular basis. 

Database access module 604 is the functionality that allows any other modules to 
create, edit, view or delete information from a database, such as staging system 216 or on- 
line system 218, that the present invention uses to store data. Database access module 604 
accepts input from release manager module 612 and provides access to the desired database, 
such as staging system 218 or on-line system 216. Database access module 604 then 
performs the required actions (e.g. create, edit, view, delete) requested by release manager 
module 612 to data in the accessed database. 

Information manager module 606 allows users to define, create, edit and delete 
objects and values associated with all data items or objects that are required for the present 
-12- 
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invention to execute correctly. Release manager 612 accesses information manager module 
606 using defined APIs to determine which data items or objects have changes pending and 
to retrieve the information for creating, modifying or deleting the data item. On an online 
system 218, release manager 612 calls information manager module 606 to apply changes to 
5 the data items. 

Authoring module 608 allows a user to define web page templates for viewing the 
catalog or other data. Authoring module 608 stores data for a page, such as a web page, in 
the system using information manager module 606 and database access module 604. 
Release manager 612 acts on data produced by authoring module 608 using information 
10 module 606 and database access module 604 as described above. 

Workflow module 610 is coupled to workflow rules module 510 and release 
manager module 612 and executes the business process and company policies defined by 
the rules of workflow rules module 510. Workflow module 610 can be setup via business 
rules to determine the sequence of events and timing of events in a release. The workflow 
1 5 module 6 1 0, using rules 5 1 0, determine whether required approvals have been given for a 
specific release. If not, the release will not be applied. If approved, the release is applied 
per the scheduling. If no rules are defined, the release process will proceed as scheduled. 
Thus, the present invention advantageously allows the release manager module 612 and the 
release process to operate according to implemented business policies. 

20 Release manager module 6 12 is a component for controlling transfers of data to an 

on-line system 218 from a staging system 216 via a network/internet link 402 in order to 
create, modify, or delete data in the on-line system 218. Release manager module 612 
embodies the logic to scan data in a staging system 216 that is scheduled to be released, 
creates a release package, moves the release package to a target online system 218 and 

25 applies changes in the release package to the target on-line system 218. Release manager 
module 612 uses database access module 604 and information manager module 606 to 
collect all changes or updates in a staging system 216 for a given release process and builds 
a release package using the collected changes or updates. Release manager module 612 
then uses database access module 604 and information manager module 606 to apply the 

30 changes to an on-line system 21 8, in other words, to create, modify or delete data items in 
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on-line system 218 based on the changes in the release package. The operation of release 
manager module 612 and the release process is described below in more detail with 
reference to Figures 8, 9, 10, 1 1, 12, 13 and 14. 

Web driver 614 is the interface between purchase manager module 308 and the Web 
5 environment. Web driver 614 accepts Web originated requests and HTTP posts and converts 
those requests into the form needed by the internal servers and processes. Web driver 614 
also performs the reverse process of converting application responses into Web formats that 
can be displayed by the Web Browsers. Web driver 614 allows modules such as authoring 
module 608, access control and administration module 602, and information manager 
10 module 606 to access and take actions on data items in staging system 2 1 6. 

Figure 7 of the drawings is a block diagram graphically showing the software 
architecture for the procurement system of the present invention. The software architecture 
includes a visual manager module 702, access control and administration module 602, a 
session manager module 706, a transaction manager module 708, procurement APIs module 

15 310, purchase manager module 308, operating system 320, a database server 618, a Web 
server 720, Web driver 614, and release manager module 612. Visual manager 702 manages 
the information system and provides a familiar and easy to use interface to the user. It is 
used for creating, managing and authoring information, setting security and other features. 
Creation of the data definition is managed through Visual manager 702 using a familiar 

20 desktop metaphor, thus hiding the complexity of the database interface. Data loading can 
also be managed remotely using Visual manager 702. Visual manager 702 seamlessly 
handles management of all data elements. For example, the image associated with a 
particular category is modified on the client desktop. This image can be loaded into the 
database from Visual manager 702 using the web browser. Bulk loading of data as well as 

25 interfacing to other database systems is also provided. Users can also extend the system and 
customize it to their needs by adding properties to categories and items through Visual 
manager 702. Properties can be global or local and shared by different logical entities. 
Session manager 706 provides a logical context for a connection to the application and 
maintains that context for the duration of the session. Transaction manager 708 ensures that 

30 any operation that needs to be executed only once and must be complete as an atomic 
operation is executed correctly and completely, or is un-done if it fails for any reason. 
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Operating system 320 is any conventional operating system, such as the Windows NT 
operating system. Database server 718 is a standard database server such as an Oracle 
workgroup server. Web server 720 is a standard web server such as the Netscape Enterprise 
server. 

A preferred method of operation and an embodiment for release manager module 
612 will be described focusing on its relationship to and its control of staging system 216 
and target on-line system 21 8. Referring to Figure 8, a flow chart of a preferred method for 
performing a release process in accordance with the present invention is shown. The release 
process provides for the modification of data, also referred to as data items, records or 
objects, in staging system 216 to affect changes in on-line system 218 for use in a 
collaborative data sharing environment. The procedure is entered at 800. The staging system 
216 is updated (802) by a user of the system by creating, modifying, editing or deleting each 
record or data in the staging system 216 that will be updated in the on-line system 218 
during a release process. The method for updating staging system 216 is described below in 
more detail with reference to Figure 9. After each record or data item has been updated, the 
updated record or data, ("update") is transferred to the packaging area. The packaging area 
is generally a file in memory used to store the update, and in one embodiment, the 
packaging area is a temporary file in staging system 216 which is used exclusively by 
release manager module 612. Each update includes all the information needed to identify 
where that updated record or data is to be applied and how and when it is to be applied in 
the target on-line system 218. In a preferred embodiment, each update contains a plurality 
of changed fields, such as a source item identifier for the source of the update, a destination 
item identifier for the destination of the update, an action field specifying the action to be 
taken, a body field containing textual and/or graphics data embodying the update, and a 
release date indicating when the action to be taken is to take place. The update is then 
packaged (804) by release manager module 612 into a package of files. Each file in the 
package contains updates of the same type. For example, in a preferred embodiment, each 
file in the package contains updates which are grouped together based on item type and 
action to be performed. A package is built once and applied to each target on-line system 
218 by release manager module 612. Once a package is built, it can be applied to multiple 
target online systems connected to the same staging system. The method for packaging the 
update is described below in more detail with reference to Figure 1 1 . The packaged update 
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is then transferred (806) by release manager module 612, preferably using File Transfer 
Protocol (FTP), from the staging system 216 to the target on-line system 218. The method 
for transferring packaged data to target on-line system 218 is described below in more detail 
with reference to Figure 12. There may be only one target on-line system or there may be 
5 several target on-line systems receiving the packaged update. After the packaged update has 
been successfully transferred to the target on-line system 218, the target on-line system 21 8 
is updated (808) by release manager module 612. The method for updating on-line system 
218 is described below in more detail with reference to Figure 13. 

A release of data from a staging system 216 to an on-line system 218 can be of two 
10 fundamental types: a full release, or an incremental release. A full release transfers a copy of 
the current data in the staging system 216 in its entirety to the online system 218. A full 
release occurs when the entire data of an on-line system 218 is replaced by the new data 
from a staging system 216. Preferably, this type of release must occur at least once before 
an incremental release can be made. For example, when a new on-line system 218 is 
15 initialized, the first release is a full release. An incremental release transfers a sub-set of data 
in the staging system 216 to the on-line system 218. An incremental release occurs at a 
scheduled time and makes specific changes to one or more on-line systems 218. The 
changes can be additions, deletions or updates to existing data. Incremental releases can 
also be run ad hoc if required to address urgent changes outside the pre-set schedule. 
20 Release manager module 612 generally controls all time related functions, and in one 
embodiment, a standard operating system service, such as KRON, is used to schedule 
releases at the defined time intervals. The release process of the present invention is 
described in more detail with reference to Figures 9, 10, 1 1, 12 and 13. 

Release manager module 612 performing the release process advantageously allows 
25 many different changes to be made concurrently to data shared by different creators of data. 
After the initial creation and installation of data on on-line system 218, the release process 
advantageously provides for the addition, deletion or modification of the data on on-line 
system 21 8 in an ordered manner to ensure that the data remains current, correct, and 
consistent. Moreover, the release process of the present invention advantageously provides 
30 for a given change to data on on-line system 2 1 8 to be implemented on a given date, also 
known as a "release date," and also provides that one or many changes may be scheduled to 
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be implemented on the release date. Thus, the release process advantageously manages the 
multiple concurrent changes to shared data on on-line system 218, ensures the consistency 
of such data, and prevents the corruption of such data which may result from conflicting 
changes made by different creators to the same data. 

5 In a preferred embodiment, procurement system module 301 includes release 

manager module 612 to perform a release process in the automation of the procurement and 
purchase of items. In such embodiment, on-line system 21 8 is the module through which 
users retrieve information, place orders, and otherwise process orders. The present invention 
operates such that there may be a plurality of such on-line systems 218. In such 

1 0 embodiment, staging system 2 1 6 i s the module to which the authors of data in the catalog, 
or the authors of processes for handling orders have access. These authors can modify the 
data in staging system 216 and specify when such changes should be made to any one of a 
number of on-line systems 218 that are in existence. Procurement system module 301 which 
includes release manager module 612 controls the updating of data on the on-line systems 

15 2 1 8 and can perform incremental updating of data to only portions of the on-line system 2 1 8 
or full updating of data where all modified portions of the on-line system 218 are made 
current. A procurement system module 301 including a release process advantageously 
provides for the modification of shared data in a collaborative environment such as the 
creation of and modification to a catalog of items that may be accessed and purchased by 

20 various users. 

Figure 9 of the drawings is a flowchart of a preferred method for updating the 
staging system 802 as shown in Figure 8. The procedure is entered at 900. The staging 
system 216 is scanned (902) for records or data that will be changed for a given release 
process. As each record or data is located, the update is applied (904) to the staging system 
216. At this stage, the status of the process is reported (906) to a staging log file by release 
manager module 612. The staging log file generated by release manager module 612 can be 
viewed by access control and administration module 602. The staging log file indicates the 
status of a particular stage of the release process and in this procedure indicates that the 
staging update has started and that the update is in progress. Typically, the staging log file is 
a standard file system kept in a system designated directory. The procedure then checks to 
determine whether the update completed correctly (908) by checking whether the scheduled 
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change was successfully applied to the staging system 216 data. If the update was 
successfully completed, then the status reported indicates that the staging update is 
completed (916). The successfully completed update is then reported (918) in the staging 
log file by release manager module 612, and the record indicating the matching change for 
5 the on-line system 2 1 8 is transferred (920) to the packaging area. If an error occurred during 
execution and the update did not complete correctly, the status reported indicates that the 
staging update has been aborted (910). The reason for the failure is recorded (912) in the 
staging log file. The update is then reexecuted (914) and the update is re-applied (904) to the 
staging system 216. Once a record or data has been successfully updated, the procedure 

1 0 determines whether another record or data needs to be updated (920). Release manager 

module 612 continually scans the staging system 216 to check for items that have scheduled 
changes for a specific date and time. Once all changes for a given release have been found, 
the process is complete. If another record or data item is to be updated for the given release 
process, steps 902 through 920 are repeated. If all records that need to be updated nave been 

15 successfully updated, the process packages the update as described below in more detail 
with reference to Figure 11. Thus, the present invention advantageously time stamps the 
changes which are to be applied to a target on-line system 218 indicating when the changes 
should be applied and hence determines a specific sequence for changes in an on-line 
system 218. Additionally, changes can be made both to items inside the database as well as 

20 to those parts of the item not located in the database, i.e. non-database parts. These non- 
database parts are usually large binary objects such as images, documents, video or sound. 

Referring to Figure 10, a flowchart of a preferred method for maintaining data 
consistency during the release process in accordance with the present invention is shown. 
The method ensures that regardless of data type, only one change is scheduled for a 

25 particular data item or record on the release date, and that once a record or data is marked as 
"to-be-deleted," no further changes are scheduled after the "to-be-deleted" date. The 
procedure is entered at 1000. The record or data is accessed (1002) and locked (1004) using 
database access module 604 to prevent others from accessing or editing the record or data. 
The procedure then determines whether the record or data is already marked for deletion 

30 (1006) by checking the action required and the required date of the update. If the record or 
data is marked for deletion, then no modifications may be made to the record or data and the 
procedure ends. If the record or data is not marked for deletion, the record or data is 
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accessed to determine the modifications and release dates (1008). The release date for this 
modification is then determined (1010). The procedure then determines whether the record 
or data is marked for change on the release date for this modification (1012). If the record or 
data is marked for change on the release date for this modification, then no further changes 
are scheduled for the particular record or data and the procedure ends. If the record or data is 
not marked for change on the release date for this modification, then the modification is 
stored (1014) to the record or data in the staging system, and the record or data status fields 
are updated (1016) by release manager module 612 through database access module 604. 

Figure 1 1 of the drawings is a preferred method for packaging the update 804 as 
shown in Figure 8. The procedure is entered at 1 100. The release date for the given release 
process is determined (1 102) from the data. Releases may be scheduled to be an automated 
release, such as a daily release, or to be a manually run release, in which case an operator 
runs the release . When a release process for a specified release date is run, all scheduled 
changes since the previous completed release process and the current date will be applied in 
sequence. All updates in the staging system 216 scheduled for release on the specified date 
are then identified (1 104) and extracted (1 106) from staging system 216 by release manager 
module 612 which copies all updates with scheduled changes to a temporary package file. 
The extracted updates are then packaged (1 108) into a file. During this stage, release 
manager module 612 reports the status to a staging log file to indicate that the packaging has 
started (1110). The procedure then determines whether the packaging completed correctly 
(1 1 12) by verifying that all updates with current pending actions are recorded in the 
package. If the packaging was successfully completed, the status reported indicates that the 
packaging has completed (1 120). The successfully completed package is then recorded 
(1 122) in the staging log file. If an error occurred and the update was not completed 
correctly, the status reported indicates that the packaging has been aborted (1114). The 
reason for the failure is recorded (1 1 16) in the staging log file. The packaging run is then 
reexecuted by repeating steps 1 108 through 1 1 12. After successful completion of the 
packaging, the procedure then determines whether any more updates need to be packaged 
(1 124) by scanning staging system 216 for updates with pending actions on or before the 
specified date for the given release process. If another update is to be packaged for the 
given release process, steps 1 102 through 1 122 are repeated. If all updates that need to be 
packaged have been successfully packaged, the process commences with the transfer phase. 
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The present invention advantageously allows updates to both database data and non- 
database data in the update procedure. 



Figure 12 is a flowchart of a preferred method for transferring packaged updates to a 
target on-line system 806 as shown in Figure 8 in accordance with the present invention. 
5 The procedure is entered at 1200. The targeted on-line system for the scheduled release is 
located (1202) and the packaged update or package is transferred to the targeted on-line 
system. As discussed above, there may be more than one targeted on-line system. In such 
cases, each targeted on-line system would be located by release manager module 612 and 
access control and administration module 602. Access control and administration module 

10 602 is usually used to regularly schedule releases for each on-line system and release 

manager module 612 will be invoked at each scheduling to perform the release process. The 
package is then transferred to each targeted on-line system. Preferably, the transfer is 
completed using FTP. Typically, release manager module 612 invokes an FTP process to 
execute the file transfer. At this stage, the status of the process is reported (1206) indicating 

15 that the transfer has started and is in progress. Release manager module 612 then checks to 
determine whether transfer of the package was successfully completed (1208). If the transfer 
was successfully completed, then the status is reported indicating that the transfer has been 
completed (1216) and the successfully transferred package is recorded in the staging log file 
(1218). If an error occurred during execution and the package did not transfer correctly, the 

20 status reported indicates that the transfer has been aborted (1210). The reason for the failure 
is recorded (1212) in the staging log file. The transfer is then re-executed (1214) and the 
package is re-sent to the target on-line system (1204). Once a package has been successfully 
transferred, the procedure determines whether another package needs to be transferred 
(1220). If another package is to be transferred for the given release process, steps 1202 

25 through 121 8 are repeated. If all packages for the given release process have been 
successfully transferred, the release process commences with the online update. 

Figure 13 is a flowchart of a preferred method for an on-line updating process 808 of 
Figure 8 in accordance with the present invention. After the package has been successfully 
transferred to the target on-line system, the on-line update phase can begin. The procedure is 
30 entered at 1300. The packaged update is opened (1302) by release manager module 61 2 and 
the record or data item in the on-line system which is to be updated is selected (1304). The 
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selected record or data item to be updated is then locked (1306) by release manager module 
612 using database access module 604 to prevent others from accessing the record during 
the on-line update. The record remains locked throughout the duration of the update. The 
update is then applied (1308) to the on-line system using the packaged update. In other 
words, the changes which were scheduled for the given release date are made to the data in 
on-line system 218. The status reported by release manager module 612 indicates that the 
online update has started and is in progress (1310). The procedure then determines whether 
the update was completed successfully (13 12). If the update was completed successfully, 
then the status reported indicates that the staging update has been completed (1320). The 
successfully completed update is then recorded (1322) in the staging log file. If an error 
occurred during execution and the update did not complete correctly, then the status 
reported indicates that the on-line update has been aborted (1314). The reason for the failure 
is recorded (1316) in the staging log file. The on-line update is then re-executed (1318) and 
the update is re-applied to the on-line system (1308). Once a record in the on-line system 
has been updated successfully, the procedure determines whether another record or data 
needs to be updated (1324). If another record or data is to be updated for the given release 
process, steps 1304 through 1322 are repeated. If all records in the on-line system that need 
to be updated have been updated successfully, the update package is closed (1326). 

While the present invention has been described with reference to certain preferred 
embodiments, those skilled in the art will recognize that various modifications may be 
provided. These and other variations upon, and modifications to the preferred embodiment 
are provided for by the present invention, which is limited only by the following claims. 
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1. A release process for creating and modifying shared data for use in a computer 
network comprising a staging system and an on-line system, the release process comprising; 

updating a record in the staging system; 

5 packaging the record into an update package, the update package indicating a 

specified time for the release process; 

transferring the update package from the staging system to the on-line system at the 
specified time; 

and updating the on-line system using the update package at the specified time. 

10 2. The release process of claim 1 wherein the step of updating a record in the staging 
system further comprises the steps of: 

scanning the staging system for the record to be updated, the record having a field 
which indicates a specified time for the release process; 

obtaining the record to be updated; and 

15 applying the update to the staging system. 

3. The release process of claim 2, wherein the step of applying the update to the record 
in the staging system further comprises the steps of: 

determining whether the update completed correctly; and 

reexecuting the update if the update was not completed correctly. 

20 4. The release process of claim 1 , further comprising the step of maintaining data 
consistency during the step of updating a record in the staging system. 

5. The release process of claim 4, wherein the step of maintaining data consistency 
further comprises the steps of: 



-22- 

SUBST1TUTE SHEET (RULE 26) 



WO 99/33007 PCT/US98/27444 

accessing the record in the staging system to be updated, the record having a 
specified time for the release process; and 



locking the record to be updated to prevent others from accessing or editing the 
record during the step of updating a record in the staging system. 

5 6. The release process of claim 4, wherein the step of maintaining data consistency 
further comprises the steps of: 

accessing the record in the staging system to be updated; 

determining modifications and release dates already stored for the record to be 
updated; 

10 determining the release date for the step of updating a record in the staging system; 

and 

determining whether modifications have already been made to the record to be 
updated for the release date for the step of updating a record in the staging system. 

7. The release process of claim 1 wherein the step of packaging the record into an 
15 update package further comprises the steps of: 

obtaining the record scheduled for release on a specified date from the staging 
system; and building an update package for each on-line system. 

8. The release process of claim 1 wherein the step of packaging the record into an 
update package further comprises the steps of: 

20 determining the release date for the current update; 

identifying records scheduled for release for the release date; 

extracting the records scheduled for release for the release date; and 

packaging the extracted records into a file for transfer to the on-line system. 
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9. The release process of claim 1 wherein the data is transferred from the staging 

system to the on-line system using FTP. 

10. The release process of claim 1 wherein the step of transferring the update package 
further comprises the steps of: 

5 locating the target on-line system to which the update package will be transferred; 

and 

transferring the update package to the target on-line system. 

1 1 . The release process of claim 1 wherein the step of updating the on-line system 
further comprises the step of: 

10 receiving the update package in the on-line system; 

locking the record to be updated; 

opening the update package; 

updating the record to be updated; and 

closing the update package. 

15 12. A method for automating the procurement and purchasing of items in a computer 
network comprising a staging system and an on-line system, the method comprising: 

a release process, for creating, modifying, and maintaining shared data in a 
collaborative environment. 

1 3 . The method of claim 1 2 wherein the release manager module further comprises the 
20 steps of: 

means for updating a record in the staging system; 

means for packaging the record into an update package; 

means for transferring the update package from the staging system to the on-line 
system; and 
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means for updating the on-line system. 

14. A system for performing a release process for creating, maintaining and modifying 
shared data in a collaborative environment comprising: 

a staging system for maintaining the created, maintained, and modified data which is 
5 to be used during the release process; 

an on-line system, coupled to the staging system, for maintaining the most current 
version of the shared data in the collaborative environment; and 

a release manager module for performing a release process. 

15. The system of claim 14 wherein the system is a procurement system for automating 
10 the procurement and purchase of items. 

16. The system of claim 14 wherein the system is a web-centric application. 

17. A system for collaborative data sharing in a computer network comprising a staging 
system and an on-line system, the system comprising: 

means for updating a record in the staging system; 

15 means for packaging the record into an update package; 

means for transferring the update package from the staging system to the on-line 
system; and 

means for updating the on-line system. 

1 8. The system of claim 1 7 wherein the means for updating a record in the staging 
20 system further comprises: 

means for scanning the staging system for the record to be updated; 

means for obtaining the record to be updated; and 

means for applying the update to the staging system. 
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1 9. The system of claim 1 7, wherein the means for applying the update to the record in 
the staging system further comprises: 

means for determining whether the update completed correctly; and 

means for reexecuting the update if the update was not completed correctly. 

20. The system of claim 1 7, further comprising means for maintaining data consistency 
during the current update to the record in the staging system. 

21 . The system of claim 1 7, wherein the means for maintaining data consistency further 
comprises: 

means for accessing the record in the staging system to be updated; and 

means for locking the record to be updated to prevent others from accessing or 
editing the record during the update process. 

22. The system of claim 17, wherein the means for maintaining data consistency further 
comprises: 

means for accessing the record in the staging system to be updated; 

means for determining modifications and release dates already stored for the record 
to be updated; 

means for determining the release date for the current update; and 

means for determining whether modifications have already been made to the record 
to be updated for the release date for the current update. 

23. The system of claim 1 7 wherein the means for packaging the record into an update 
package further comprises: 

means for obtaining the record scheduled for release on a specified date from the 
staging system; and 

means for building an update package for each on-line system. 
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24. The system of claim 1 7 wherein the means for packaging the record into n update 
package further comprises: 

means for determining the release date for the current update; 

means for identifying records scheduled for release for the release date; 

means for extracting the records scheduled for release for the release date; and 

means for packaging the extracted records into a file for transfer to the on-line 

system. 

25. The system of claim 1 7 wherein the means for transferring the update package 
further comprises: 

means for locating the target on-line system to which the update package will be 
transferred; and 

means for transferring the update package to the target on-line system. 

26. The System of claim 17 wherein the means for updating the on-line system further 
comprises: 

means for receiving the update package in the on-line system; 
means for locking the record to be updated; 
means for opening the update package; 
means for updating the record to be update; and 
means for closing the update package. 



-27- 

SUBST1TUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



1/13 




SUBSTITUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



2/13 



200 



202 s 



Processor 



204- 



Memory 



206 



Storage Device/ 
Hard Disk 



Staging 
System 
216 



On-line 
System 
218 



-214 



Bus 



-208 



Input Device 



210 



Output Device 



-212 



Network/ 
Internet Link or 
Interface 



FIG. 2 



SUBSTITUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



3/13 



204 



301 



302 - 



Open System 
Interfaces 



304 ^ 

Functional 
Components 



306 ^ 



Component 
APIs 



308 - 



Purchase 
Manager 



322 « 



API 



- 310 



Procurement 
APIs 



-312 



PR Application 



-314 



PR API 



- 320 



Operating 
System 



FIG. 3 

SUBSTITUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



4/13 

206 



216 


^ 218 


Staging 






On-line 


System 






System 


216 ^ 


^-404 


Staging 






Back-end 


System 






System 







FIG. 4 



SUBSTITUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



5/13 



308 



502 ^ 


c 514 


Catalog 






Purchasing 


Browser 






Administration 


504 ^ 


s 512 


Shopping 
Basket 
Manager 






Purchase Order 






Manager 


506 ^ 


^ 510 


Purchase 
Requisition 
Manager 






Worktlow 






Rules 







FIG. 5 

SUBSTITUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



6/13 

304 



602 ^ 


^ 608 


Access Control 

and 
Administration 






Authoring 






604 ^ 


^ 610 


Database 






Workflow 


Access 






606 


^ 612 


Information 






Release 


Manager 






Manager 




^614 






Web Driver 











FIG. 6 



SUBSTITUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



7/13 



702- 



Visual Manager 



602- 



Access Control and Administration 



706- 
708 " 



308 ' 



Session Manager 



Transaction Manager 



Procurement API 



310 



Purchase Manager 



Operating 
System 



Server 



320 



718 



Web Server 



720 



Web Driver 



614 



Manager 



7- 

612 



FIG. 7 



SUBSTITUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



8/13 

Release Process 



( Start ^ 800 







Update the Staging System 






Package the Update 






Transfer the Update from the 
Staging System to the On-line 
System 






Update the On-line System 







( End ) 

FIG. 8 



SUBSTITUTE SHEET (RULE 26) 



PCT/US98/27444 



9/13 



( Start V - 900 

| 902 



Scan Database for Record to be Changed 

+ 



Apply Update to Staging System Database 



T 



Report Status: Staging Update Started 



-904 
-906 



Did Updat<3^\^ Yes 



< — Complete Correctly^-> 








Report Status: Staging Update Aborted 


— 910 


♦ 




Record Reason for Failure in Staging Log File 


— 912 






Re-execute Update 


— 914 




^ 916 


Report Status: Staging Update Completed 





Report Successfully Completed Update 
in Staging Log File 

f 



^ 918 



Transfer Record Indicating Matching Change 
for On-line System to Packaging Area 




SUBSTITUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



10/13 



Editing/Modifying for 
Staging 



( start ) 



Access Record 



Lock Record to Prevent Others 
from Accessing or Editing 



Access Record to Determine 
Modifications and Release Dates 



-1004 




-1008 



Determine the Release Date for 
This Modification 



Store Modification to Record in 
Staging Version 



-1010 




-1014 



Update Record Status Fields — ■ 1016 



FIG. 10 

SUBSTITUTE SHEET (RULE 26) 



PCT/US98/27444 



11/13 



| ^ 1102 



Determine the Release Date for Release 



Identify Data Scheduled for Release 
on Release Date 



Extract Data Scheduled for Release 
for Release Date 



Package Extracted Data into a File 

i 



Report Status: Packaging Started 



- 1104 

- 1106 
-1108 
M110 



JL 1112 


Correctly 








Report Status: Packaging Aborted 


^ 1114 


1 




Record Reason for Failure in Staging Log File 


— 1116 


t 




Re-execute Packaging Run 


— 1118 




[-3-1120 


Report Status: Packaging Completed 





Record Successfully Completed Package 
in Staging Log File 




( &d ) 

.11 

SUBSTITUTE SHEET (RULE 26) 



PCT/US98/27444 



12/13 



( Start ^ 1200 



Locate Target On-line System 




lui l lailoiclllliy rctUrvdyil iy 




' " " T — 1 

T 




Transfer Package to Target On-line 
System 


- — ' 1204 


1 

JIL f 1206 
^^DicT^. 
Transfer Complete 




^\_^Correctly^ 




jNo 




Report Status: Transfer Aborted 


^ 1208 


1 




Record Reason for Failure in Staging Log File 


— - 1210 






Re-execute Transfer Run 


— 1212 




f~ 1214 


Report Status: Transfer Completed 




* 




Record Successfully Transferred Package 
in Staging Log File 


^ 1216 




( End ) 



FIG. 12 

SUBSTITUTE SHEET (RULE 26) 



WO 99/33007 



PCT/US98/27444 



13/13 



Open Update Package 


— 1302 


1 

I I c 


— 1304 


Select Record to be Updated 










Lock Record Being Updated to 
Prevent Others from Accessing 


— 1306 






Apply Update of Record to On-line 
System Database 


— 1308 


i 




Report Status: On-line Update Started 


— - 1310 


jL ^-1312 
/-^Did^<^ 
< ^ Update Complete Yes 




Correctly 






|No 






Report Status: On-line Update Aborted 


^1314 




1 






Record Reason for Failure in Staging Log File 


— 1316 




t 






Re-execute Update 


— 1318 






^ 1320 




Report Status. On-line Update Completed 










Record Successfully Completed Update 
in Staging Log File 


— 1322 


^X^s 1324 
_^^^MJpdate~^^^ Yes 




<C^Ajiother Recor^ i0 ^> 




^1326 




Close Update Package 





FIG. 13 C End ) 

SUBSTITUTE SHEET (RULE 26) 



INTERNATIONAL SEARCH REPORT 





Inte icnal Application No 

PCT/US 98/27444 


A. CLASSIFICATION OF SUBJECT MATTER 

IPC 6 G06F17/30 








According t 


5 International Patent Classification (IPC) or to both national classific 


ation and IPC 






B. FIELDS SEARCHED 


Minimum documentation searched (classification system followed by classification symbols) 

IPC 6 G06F 


Documentation searched other than minimum documentation to the extent that < 


uch documents are inc 


uded in the fields a 




Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 


C. DOCUMENTS CONSIDERED TO BE RELEVANT 


Category 0 


Citation of document, with indication, where appropriate, of the relevant passages 




X,P 

Y 
X 

Y 


US 5 701 457 A (FUJIWARA SHINJI) 
23 December 1997 

see column 1, line 32 - column 4, line 68 
see abstract 

PATENT ABSTRACTS OF JAPAN 

vol. 096, no. 009, 30 September 1996 

& JP 08 129501 A (HITACHI LTD), 

21 May 1996 

see abstract 


1-4, 
6-10, 
12-20, 
22-25 

5,11,21, 
26 

1-4, 

6-10, 

12-20, 

22-25 

5,11,21, 

26 


| X] Furtner documents are listed in the continuation of box C. 


[X~| Patent family 


members are listed 




• Special categories of crted documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
"E" earlier document but published on or after the international 

filing date 

"L" document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 

"P" document published prior to the international filing date but 
later than the p riority date clai mod 


T" later document pub 
or priority date an 
cited to understan 

X" document of panic 
cannot be conside 
involve an inventiv 

Y" document of partici 
document is comb 
Snlheart 1011 

&' document member 


ished after the inte 
not in conflict with 
d the principle or trx 

lar relevance: the c 
red novel or cannot 
e step when the do 
lar relevance: the c 
edto involve an in 

nation being obvio 
ol the same patent 


mational filing date 
the application but 
ory underlying the 

be co d nsidered°to 
cumentis taken alone 
aimed invention 
entive step when the 
re other such doou- 
jstoa person skilled 


Date of the actual completion of the international search 

22 April 1999 


Date of mailing of the international search report 

29/04/1999 


Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL-2280 HV Rijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl 
Fax: (+31-70) 340-3016 


Bowler, 


A 





Form PCT/ISAI21 o (second sheen (July 1 992) 



page 1 of 2 



3 



INTERNATIONAL SEARCH REPORT 


lnt> ;ional Application No 

PCT/US 98/27444 


C(Contlnuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 




Citation ot document, with indication.where appropriate, of the relevant passages 


Relevant to claim No. 


Y 


US 5 008 853 A (BLY SARA A ET AL) 

16 April 1991 

see column 10, line 21-26 

see abstract 




5,11,21, 
26 


A 


WO 95 08809 A (ORACLE CORP) 30 March 1995 
see abstract 

see page 7, column 1 - page 8, column 20 




1-26 



Form PCT/ISA/21 0 (conanuaiion ol second sheet} (July 1 992) 



page 2 of 2 



INTERNATIONAL SEARCH REPORT 



n patent family members 



PCT/US 98/27444 



8129501 A 



DE 
DE 
EP 

JP 

US 



3854994 D 
3854994 T 
0319232 A 
2002450 A 
5220657 A 



AU 
CA 
DE 
GB 
US 
US 



7684094 A 
2172517 A 
4497149 T 
2297181 A, I 
5806075 A 
5737601 A 



21-05-1996 



21-03-1996 

14- 11-1996 

07- 06-1989 

08- 01-1990 

15- 06-1993 



10-04-1995 
30-03-1995 
17-10-1996 
24-07-1996 
08-09-1998 
07-04-1998 



Form PCT7ISA/210 (patent lamiy annex) (July 1992) 



